Turnbull China Bikeride/Turnbull China Bikeride - Disc 2.iso/BARNET/INTERNET/ACORNET/ACORN-ST/ACRNET21/!AcornetA_Docs_FreeSMTP

Text File | 1997-02-28 | 36.8 KB | 1,001 lines

!FreeSMTP 1.21
==============

Contents:
    Copyright & Disclaimer
    Important Changes in this Version
    Installation Instructions
    Upgrading from Earlier versions
    Configuration Instructions
        Why does all email get sent to "localhost"
    Operating Advice
        for people with permanent links
        for people with transient dialup links
    Running & Stopping !FreeSMTP
    What to do if you get the error message:
        Loopback interface is not configured/up
        Loopback interface is configured - but not up
    Kicking the sender
    Activity log
    References
    Bug Reporting
    Technical Details
        MX records explained
        Security Considerations
        Ident
    ChangeLog


**** WARNING: Incorrect configuration can cause you to be in breach
**** of your provider's terms & conditions.  Full details under the
**** configuration section below, in the subsection "forwarder"




Copyright & Disclaimer
----------------------

This program is copyright (C) Stewart Brodie, 1996, 1997

The author accepts no liability for any damage or loss of any kind incurred,
or allegedly incurred, by the use, or misuse, of this software.  The program
may do its absolute best to ensure that incoming mail is either stored
successfully in the incoming (or outgoing) mail spool appropriately, or that
the sender is informed that the delivery attempt was unsuccessful and should
be retried (or not as appropriate).

Having said all that, I do want people to use it and find any problems.  I'm
afraid that some people's attitude make all those disclaimers necessary.  For
normal usage, there shouldn't be any problem, and the programs try very hard
indeed to prevent any loss occurring (eg. by not acknowledging successful
reception of an e-mail until it has been successfully stored in the spool
directory completely).  If the program fails, then in the vast majority of
cases the upstream SMTP will have received a rejection from this program
(unrequested connection termination counts as a rejection unless the 250
response to the final '.' of a DATA body is received at the sender).  If the
sender half of this software fails, then it it will construct a failure
message and return that directly to the message originator.



Important Changes in this Version
---------------------------------

Issuing a DATA command at the wrong point no longer results in two responses
being sent.

From older versions:

A bug whereby the sender fails to start due to a memory shortage and then
will never start again (until FreeSMTP is reloaded) has been cured.

I've implemented a fix for the forwarding rules which should make the
forwarder lines behave completely intuitively.  If people find problems,
I'd like to know bout them, please.


Installation Instructions
-------------------------

Installation should be fairly simple and trouble free provided these
instructions are followed carefully.  You will NEED Newsbase 0.55 or later
in order for this to work properly - it will not like 0.54.  I have tried
to include as much details as possible, so don't worry about the apparent
length of it.

* Copy the Transports directory into the !Newsbase directory to install the
interface programs in Newsbase. (You may find that you have to restart
Newsbase now to get it to recognise the newly present transport).

* Copy the !FreeSMTP directory into a directory containing your other
Internet applications, and run it in its new home (it will fail to start
because there is no configuration file, but this step is necessary in
order to reset the system variables to point to the correct directory)

* Open the Newsbase Transport Control window, and in the middle portion
of this window, choose "in_smtpd" off the Transport menu.  You should now see
the description "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)" or similar.  If
you fail to get this far, then you may have forgotten to restart Newsbase or
to rerun !FreeSMTP.

* Switch on the Check arrivals new mail option.

* Follows the instructions in the Configuration Instructions below

* Ensure you have a DNS resolver configuration file.  If you do not have a
DNS resolver installed on your system, then you will need to get one.  You
can find this out by looking for a file in !Internet.Files (or
!FreeUser.Files or !InetSuite.Internet.Files) called "resconf".  If this is
present, then you have already got the necessary file installed.  The
resolver module is NOT used, but the configuration file it uses IS used by
these programs (FreeNet (by Tom Hughes) comes with InetDB and its
installation instructions; ArcWeb (my program) comes with just the
installation instructions necessary)


Upgrading from Earlier versions
-------------------------------

Reinstall the Transports into !Newsbase.  If you changed the log file
locations in !Run, re-edit the *new* !Run since this contains new
system variables that are required.

Your mail is received into a different directory than before version 1.14.
This makes it compatible with the KA9Q directory structure.

You should read the section on 'noiconbar' in the configuration section as
this is a new command.


Configuration Instructions
--------------------------

There is a single configuration file for !FreeSMTP which is stored
inside the !FreeSMTP directory.  This is deliberately entirely made
up of comments so that the programs will refuse to load before you
have edited the configuration.  You should find that you can skim
through this section, modifying the file as you go.

(If !FreeSMTP.smtp-conf does not exist, then either copy it from defaultcnf
in the same directory, or click on Setup in the Newsbase Transport Control
window which will do this for you)

The configuration file is a sequence of directives which tell the
software what your machine's real name is, what e-mail domains it
hosts, and which domains it relays mail for (if any).  I have tried
to provide as much flexibility as possible whilst keeping it as
simple as possible for the vast majority of cases (take a look at an
/etc/sendmail.cf file on a UNIX system to see how hairy it can become :-)

To edit the configuration file, choose the "in_smptd" transport in the
Newsbase "Transport Control" window.  You should then see the description
message "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)".  To set up the Newsbase
bit, ensure that "Check arrivals: new mail" is set; Route outgoing mail is
set, and a smarthost is placed in the gateway box for mail(**).  Also set
in_smtpd as the Def mail route.  Then, you should click on the Setup button
which will open the configuration file in your text editor ready for you
to set your own site details.

(**) If you set the gateway to be your own machine, then you MUST have
     an appropriate forwarder line as described below.  The line you
     will need will be "forwarder * provider's-smarthost".

Provided you have set up the forwarder lines, you can tell any software
you have to send outgoing mail to 'localhost'.  This will result in it
being sent to the server which will then route it using the rules in
smtp-conf without consulting Newsbase.

There are brief comments in the configuration file to remind you what each
section is for, but these are elaborated here.  The order of the sections is
not important, although the order of declarations of the same type IS
important (see below for reasons) For each section I have given the syntax,
an example for a Demon DialUp user with a nodename of 'customer',
(applicable to other static IP single host systems too), an example for a
host on a network handling mail for that network, and my own setup.


hostname
========

Syntax:   hostname <Fully Qualified Domain Name (FQDN)>
Demon DU: hostname customer.demon.co.uk
Network:  hostname mail.an.org.uk
My Setup: hostname delenn.ecs.soton.ac.uk

This gives the *full* hostname(s) of the machine running this software.
Hosts may have more than one name in some circumstances, and this is
allowed by having multiple hostname lines, although the *first* line
found in the file is the one used to identify the server to remote
hosts when it needs to (eg. when greeting SMTP clients)

localdomain
===========

Syntax:   localdomain <Fully Qualified Mail Domain> [<alias name>]
Demon DU: localdomain customer.demon.co.uk
Network:  localdomain an.org.uk
My Setup: localdomain delenn.ecs.soton.ac.uk soton

[and in My Setup, <SMTPServer$Aliases>.soton contains the line:
S.N.Brodie snb94r
]

This gives the local *mail* domain(s) handled by the software.  These
mail domains are the things you see after the @ in mail addresses.
When mail arrives, the destination is checked to see if there is any
@ character in it.  If there is NOT, then the value of the *first*
localdomain directive is assumed.  (This is so that the alias and user
list functions can determine which set of aliases to apply)

Next, the bit after the @ is compared against each localdomain directive in
turn.  If it matches any one of them, then the domain part is dropped. Next,
if an alias name was specified for that localdomain, then the bit before the
@ is looked up in <SMTPServer$Aliases>.aliasname to see if was a mail alias,
and if so, the mail address is rewritten to match the definition of the
alias.  The format of that file is described below.  You MUST be careful with
that file.

Otherwise, the bit before the @ is assumed to be a mailbox in the local
Newsbase. (If no domains match, then it is checked against the forwarders
below).

If you wish to have an mailbox name that contains characters illegal in RISC
OS filenames, then you can create an alias to convert it to something else,
like I do in my alias file as shown above.

For single dialup hosts, there is likely to be a single setting which
will happen to co-incide with the hostname.  For hosts serving entire
domains, this is less likely. (Note that in My Setup, I accept mail for
an unofficial mail domain - you won't find an MX record in the DNS for
the delenn.ecs.soton.ac.uk mail domain)


alias file format
=-=-=-=-=-=-=-=-=

The format of the file is that the alias appears first on the line, and
the real addresses are specified after it separated by whitespace.  If
you need to use more than one line, then these continuation lines MUST
start with whitespace (otherwise they are considered to be other aliases)

Although this might seem like a good way to set up a mailing list, this
is NOT the case, since the original sender will be in the FROM envelope,
so any forwarding errors will go to there and not to some mailing list
software.

The purpose of the alias file is for *simple* rewriting and occasional
duplication if you need it.  If you want to run a mailing list, then
use something like !MailList.

So in My Setup mentioned above shows that any mail incoming addressed
to [e-mail] will be sent to snb94r.  This is
useful because you can specify names which might not be acceptable as
usernames to Newsbase.



forwarder
=========

Syntax:   forwarder <"*" | F.Q. Mail Domain> <"MX" | smarthost-FQDN>
Demon DU: forwarder * post.demon.co.uk
Network:  forwarder * MX
          forwarder * mail.smarthost.provider.org
My Setup: forwarder ecs.soton.ac.uk MX
          forwarder * dsse.ecs.soton.ac.uk


This gives mail domains which are to be responded to by the software, but
which are not local to this machine (ie. they need to forwarded on somewhere
else, cf. localdomain).  For the vast majority of people, you will want one
forwarder line (see WARNING below - having such lines may in fact
contravene your provider's terms & conditions of service unless you have
specifically purchased the right to forward mail).

The major purpose of the non-* entries here is when you are running FreeSMTP
on the mail gateway for a domain (ie. the MX record for a domain gives
the machine running FreeSMTP as one of the mail exchangers).

If there are no forwarder lines, then any mail not destined for local
delivery (ie. it matched one of the localdomain lines) will be rejected when
it is offered by another host (*).

If there are forwarder lines, then they are matched in order.  If the first
parameter is "*", then this matches, otherwise the string has to match the
bit after the @ in the destination of an incoming mail exactly.  The second
parameter describes how this forwarding is to be achieved and is either the
string "MX" or the FQDN of a smarthost which will do the job for you.

There are two ways of forwarding the mail - MX records, and smarthosts. Using
MX records involves looking up the name of the machines which handle mail for
a given mail domain (see description later in this document) and then sending
the mail directly to one of those machines.  The alternative is to use a
'smarthost' (such as post.demon.co.uk) which will perform that function on
your behalf (ie. it acts as an intermediate relay for you). The advantage of
using MX records, is that it bypasses your provider's smarthost (less hops to
the destination) and can tolerate the smarthost being down.  When MX lookups
return multiple records, they are tried in turn according to the priorities
specified by the DNS server. [This does seem to work, as I found out when
Demon's punts weren't accepting mail and when the connection attempt to them
timed out, it sent it to relay-1 instead :-) ]

(*) 'another host' could actually be your own machine.  For example, I
have ArcWeb's Email configuration set up with a smarthost mail gateway
of "localhost".  This means that ArcWeb will send mail by talking to the
SMTP server process running on my own machine.  Thus, having no forwarder
lines in my configuration would mean that I couldn't send mail that way
and would have to configure a remote smarthost in ArcWeb instead.


forwarder strategy
-=-=-=-=-=-=-=-=-=

The forwarder directives which specify MX records are to be used are
overridden in some circumstances, primarily for performance reasons.

If the mail has only a single recipient (or multiple recipients with the same
domain) and forwarder says to use MX records, and those MX records exist,
then this will happen.

If the mail has multiple recipients, then any MX directive is overridden and
a smarthost is used instead *if one is defined* (because otherwise the
message would have to be sent separately to each recipient).  [A future
enhancement will be to still use MX records if all the destinations share a
common mail exchanger]


WARNING: Incorrect configuration of forwarder records could cause you
         to be in breach of the terms & conditions of your account.
         Unless you are authorised to forward mail to hosts other than
         those at your provider's end of your connection, you should
         only have one forwarder line:

        forwarder * post.demon.co.uk

         (where you have substituted your provider's smarthost for
         post.demon.co.uk if you aren't with Demon Internet)

         The author accepts no responsibility or liability for any
         such breaches of terms & conditions, nor for consequences
         arising from action taken by providers against any user of
         this software for such breaches even if the author has been
         advised of the possibility of such breaches.


acceptfrom
==========

Syntax:   acceptfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
Demon DU: (no acceptfrom lines)
Network:  (no acceptfrom lines)
My Setup: (no acceptfrom lines)

** WARNING: If you use hostnames with this command, then these must be
**          resolvable when the program starts, otherwise the directive
**          will be ignored.

This is used to selectively choose which remote hosts you are willing to
accept mail from.  If a host other than one listed attempts to deliver
mail to your machine, then it will be told that it does not have permission
to deliver mail to your machine.  If there are no acceptfrom lines (as in
My Setup) then any host may connect.

When specifying an IP address, you may specify the number of significant bits
to be matched (as described in the rejectfrom section below)

All addresses that pass the acceptfrom directives (including the case
where there are NO acceptfrom directives) are then validated against
the rejectfrom directives described in the next section.

IMPORTANT:  If you have any of these fields, then you MUST include
all the machine's own IP addresses and you MUST include localhost (ie.
127.0.0.1), since the outgoing sender may use these addresses when
constructing error notifications and performing mail rewriting.

There is little real reason to use this facility unless you are worried
about faked e-mail being sent via your site (and even then, the message
is tagged with the Received line containing the IP address of the sender,
allowing you to trace the source)

See also: rejectfrom, killfile

rejectfrom
==========

Syntax:   rejectfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
Demon DU: rejectfrom 198.81.0.0/16
          rejectfrom 152.163.172.0/24
Network:  rejectfrom relay.deliverer.hackers.org
My Setup: (no rejectfrom lines)

** WARNING: If you use hostnames with this command, then these must be
**          resolvable when the program starts, otherwise the directive
**          will be ignored.

This is used to selectively choose which remote hosts you are NOT willing to
accept mail from.  If a host covered by one of these directives, then it will
be told that it does not have permission to deliver mail to your machine.  If
there are no rejectfrom lines (as in My Setup) then any host may connect
(subject to the acceptfrom conditions).  The Demon DU example describes that
mail from 198.81.xxx.xxx and from 152.163.172.xxx will be rejected (these
are the AOL mail exchangers :-)  I am not suggesting that you do this - just
using it as an example of use.

IMPORTANT: You should not reject any of your machine's own IP addresses
(including 127.0.0.1 (localhost)).  See also: acceptfrom, killfile

There is very little real reason to use this facility unless you have
some hacker trying to send you mail, in which case you can block their
IP address using this facility.


killfile
========

Syntax:   killfile <Fully Qualified Kill File path name>
Demon DU: killfile smtpserver:killfile
Network:  killfile smtpserver:killfile
My Setup: killfile smtpserver:killfile

This is used to kill incoming mail based on the *sender* specified
in the SMTP envelope (ie. the MAIL FROM).  The file named in the
directive is consulted when a new transaction is started and if
the sender matches any entry, the mail is rejected.

The kill file format itself is one (wildcardable) address per line.
If the kill file does not exist, nothing is killed.


noexpand
========

Syntax:   noexpand
Demon DU:
Network:  noexpand
My Setup:

This directive is optional and takes no parameters.  If it is present,
then clients attempting an EXPN on an alias will receive a message
indicating that EXPN has been explicitly disabled by the administrator.

If you don't understand the above paragraph, then you don't need this.

Normally, you'd only use this to stop people looking up the members of
a mailing list of something like that.  The vast majority of people
do not want this.


noident
=======

Syntax:   noident
Demon DU:
Network:  noident
My Setup:

This directive is optional and takes no parameters.  If it is present,
then the server will not attempt an ident request to the client making
the connection.  See "Remote User Authentication" section below for
more details of ident.

If you don't understand the above paragraph, then you don't need this.

You would only ever disable this feature for efficiency reasons.

noiconbar
=========

Syntax:   noiconbar
Demon DU: noiconbar
Network:
My Setup:

This directive is optional and takes no parameters.  If it is present,
then no icon bar icon will be installed.

You would only ever disable this feature to avoid filling your iconbar.
If you have this directive, the only way to stop FreeSMTP is to double-
click on FreeSMTP again.


maxhops
=======

Syntax:   maxhops <maximum hop count>
Demon DU:
Network:
My Setup:

This directive is optional and defaults to "maxhops 30".  The numeric
parameter describes the maximum number of servers through which the mail is
allowed to be passed before being returned to the sender as undeliverable.
Usually, mail will take at most half a dozen hops to get to the recipient.
If it is up to something more like 30 (the default here), then it is likely
that a mail loop has developed (a set of servers (mis)configured to route
mail for the destination domain to each other, which will just keep
forwarding it back and forth forever and ever).  Once maxhops is exceeded,
this server will not forward it any more, but will construct a delivery
failure message and bounce it back to the sender.

Almost certainly, you do not want to override the default.


maxsessions
===========

Syntax:   maxsessions <+ve integer>
Demon DU: maxsessions 4
Network:  maxsessions 4
My Setup: maxsessions 4

This specifies the maximum number of sessions that may be in progress at
any one time.  This is limited by the capability of the C library (and if
you specify a number too large, it will be reduced to the maximum that can
be supported - 4 with the current SharedCLibrary.

It is important to have this set to 4 for Demon customers, since Demon
have multiple mail machines which may attempt delivery concurrently.


Why does all email get sent to "localhost"
------------------------------------------

All e-mail sent by your machine will be sent initially to the server on your
machine.  (tech: the GATE command in the work file will always be set up
to be "GATE VIA:localhost").  This is deliberate, because all the mail
routeing cleverness is stored in the *server* at the moment.  That software
can then make the final destination decision and requeue it for sending out.

This will cause an extra Received header to be placed in the outgoing mail,
and will also ensure that missing headers are inserted before the mail
leaves your machine too.

This is not a really peculiar thing to do.  Most UNIX machines I have used
have done this.  It is done to simplify the coding of the mail senders and
to centralise the decision making process and forwarding rule processing
into a single place so that policy changes can be implemented in one go.


Operating Advice
----------------

for people with permanent connections
=====================================

Run it all the time - that's what I do.


for people with transient dialup links
======================================

You really do want to start the TCP/IP stack and !FreeSMTP *before*
connecting to the net.  This is particularly important for Demon users, since
the SMTP server takes around 1 second to start up and read its configurations
files and may not manage to start listening for the incoming connections
before the punts attempt to deliver mail (they fail to do so, and hold on to
it for a while before trying again a bit later).  This causes a slight
problem with dialup lines though unless you are careful.  You *must* start
the TCP/IP stack, but you do NOT need to start up the SLIP/PPP interface (if
you do, your dialler won't be able to access the comms port!).  The relevant
bits that must be deferred until after dialling is complete are the slattach
& ifconfig commands


Running & Stopping !FreeSMTP
----------------------------

Run !FreeSMTP by double-clicking on the icon in the directory viewer.
To stop, it double-click on the icon again (or kill SMTP Monitor in
the Task display window) or choose Quit from the icon bar menu if you
haven't disabled the Wimp interface (see "noiconbar" directive above)


What to do if you get the error message:
    Loopback interface is not configured/up
    Loopback interface is configured - but not up
-----------------------------------------------------

These two messages are new in version 1.17.  If you get them, then you
will find that the program will not have started.  FreeSMTP needs the
loopback interface configured.  This should have been done during your
boot sequence, or whenever the TCP/IP networking software was loaded.

If you get the latter of the messages (which would be unusual unless
you were fiddling around), then you need to issue the command:
"*ifconfig lo0 up" at the command line or insert this in the networking
startup files.

If you get the former, then you need to insert the slightly longer:
"*ifconfig lo0 inet 127.0.0.1 up".

Once these commands have been executed, FreeSMTP should load.   If it
still doesn't, then the chances are you that are using an old version of
FreeNet.  Edit !FreeSMTP.!Run and insert the following line:

Set SMTPServer$NoSearch 1


(See also: Why does all email get sent to "localhost")



Kicking the sender
------------------

The sender program (out_smtpd) is automatically launched (by SMTP Monitor)
after in_smtpd has queued a mail in the outgoing queue, or the sendmail
Newsbase transport has queued a mail there.  You can kick it by choosing
"Kick" on the icon bar menu (see "noiconbar" directive) or double-clicking on
!SendSMTP (inside !FreeSMTP).

After being loaded, it will wait 30 seconds, then 1 minute, then 2, 4, 8,
then 16 minutes, and thereafter every 30 minutes. This is in addition to the
other times when it is kicked manually or by the server.


Activity Log
------------

This software contains inbuilt activity logging which it will dump to
the files clnt_log & mon_log inside the !FreeSMTP directory.
The amount of debugging and which debugging is controlled by a file called
area_log, also inside !FreeSMTP.  This contains one string per line
containing a case-sensitive string to match against those used in the code.
(* is used as a wildcard which matches every string).  Examples of these are:

    domain_init
    process_mail
    verify_dest

Vital messages are always logged if possible.  The file is left open
whilst the server is actively writing to it and closed after a short
delay if nothing is written to it, for efficiency reasons.  The location
of the log file can be altered by editing !Run and changing the settings
of the three <SMTPServer$xxxxxLog> variables.

These will need to be cleared out every now & again.

If you place a line containing just a single * character in this file, then
everything will be logged to this file, this will help provided more details
if you are having problem.  If you send me this file when reporting faults,
then it is more likely that I shall be able to help.  If you do this, then
the log file will grow very quickly.  Only use it when attempting to capture
debug trails for me.


References
----------

RFC821 - Simple Mail Transfer Protocol

RFC1123 - Requirements for Internet Hosts

RFC1413 - Identification Protocol


Bug Reporting
-------------

There are bug reporting features built-in to the software.  If you edit
the file !FreeSMTP.area_log and add a new line at the bottom containing
just an asterix (*), then all debugging information will be sent to the
files, and not just the really important ones.  These document some of
the decisions made by the software and will contain justification for
those decisions.

Please give as much detail as possible when reporting bugs.  Include the
e-mail message that caused the problem if possible.  NOTE:  If you do not
wish to disclose the identities of the sender/recipient, then please feel
free to overwrite it with something else - use * characters for example -
but please do NOT just remove it.  If you do choose to delete parts of it,
then please only delete the bits before the @ in the address.  You may
also like to remove most of the message body.

Bug reports to [e-mail] please


Technical Details
-----------------

I have included this section for those who are interested.  It does not
matter if you do not want to read any more of this document.

MX Records Explained
====================

Briefly.  You are probably familiar with the concept of hostnames (eg.
customer.demon.co.uk, www.demon.co.uk, sunsite.doc.ic.ac.uk).  The mappings
between these and the 4 byte numeric IP addresses (eg. 152.78.67.42) are
registered in the Domain Name System's 'A' records (A for address).  Mail
domains look very much like hostnames, and in some cases happen to be the
same, but this is coincidence (but arranged like that because it's easier to
remember :-)   Mail domains are also registered in the Domain Name System,
but they do NOT map to IP addresses, but to 'Mail eXchangers'.  These mail
exchangers are simply the hostnames of machines which handle mail for that
mail domain.  For example, when software is using MX records to send me mail,
it looks up the MX records for 'ecs.soton.ac.uk'.  The response it will get
will be something similar to:

ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.

This indicates that bright.ecs.soton.ac.uk (which when looked up, is found to
have the address 152.78.64.201) is a machine which handles mail for
'ecs.soton.ac.uk'.  landlord.ecs.soton.ac.uk is also reported as a mail
exchanger (so when bright is down, we can still receive mail), but the lower
number indicates that bright is the preferred exchanger, and landlord the
backup.  If you perform a similar lookup on any Demon customer domain,
usually you will find 4 or 5 records, with varying priorities.  Although it
would appear that lots of DNS lookups are required in order to find the
addresses of these mail exchangers, that is not the case typically, as the
full response from the DNS for the question "ecs.soton.ac.uk IN MX" will be
(if not querying one of our authoritative nameservers in Southampton):

Questions:
ecs.soton.ac.uk. IN MX

Answers:
ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.

Additional:
bright.ecs.soton.ac.uk IN A 152.78.64.201
landlord.ecs.soton.ac.uk IN A 152.78.114.230

Authority records:
dns0.ecs.soton.ac.uk    inet address = 152.78.64.201
dns1.ecs.soton.ac.uk    inet address = 152.78.114.230
dns0.brad.ac.uk inet address = 143.53.240.2
dns0.brad.ac.uk inet address = 143.53.2.5
dns1.brad.ac.uk inet address = 143.53.238.5

ie. since it is assumed that you will probably want the IN A record for
each mail exchanger, the DNS server includes those records in its answer
which you may need.  Since you may not 'trust' the nameserver, it also tells
you machines that are the authoritative DNS servers for the ecs.soton.ac.uk
internet domain.  The auth records show the names of our primary and
secondary DNS servers, plus our offsite authority nameserver (an Internet
requirement) at Bradford.


Remote host authentication
==========================

When a connection is accepted, the peer IP address is looked up in the DNS.
Since this lookup is initiated immediately, then the lookup is often
complete before the HELO arrives (and the HELO parameter can thus be
authenticated immediately).  The domain name specified as the parameter to
HELO is used in the Received header which is added by the smtp server to
the incoming message, together with either the IP address of the remote
host, or the name as obtained from the DNS.

NOTE: Mail will NOT be rejected if the HELO domain fails to authenticate.
This is RFC-compliant behaviour (it is not allowed to reject on the basis
of the HELO domain).


Remote user authentication
==========================

When a connection is accepted, then an ident request is sent to the origin
machine requesting the user identity of the sender.  (This is not done if
the configuration file contains a "noident" directive).  This is logged
with area "ident" (so place "ident" in area_log to see it in smtp_log).

NOTE: You cannot rely on this, particularly on the user id returned. See
RFC1413 for more details about the (lack of) confidence that you should
have in the ident response.

NOTE 2: You might decide to disable this, but usually only because the
overhead of establishing a TCP connection to the client wastes resources.
The bandwidth used is negligible though (on average about 10 bytes out,
and 25-50 bytes back).


Attacks & Security Considerations
=================================

Simple denial of service attacks are prevented (limits on number of
recipients for message plus limits on number of concurrent connections)
The recipient limit is set to 100 (minimum requirement in RFC821)

Idling attacks are repelled by implementing the timeout strategy given
in RFC1123.

Well faked e-mail can never be detected successfully, but the addition
of the Received header to incoming message bodies will assist in the
tracing of injection points into the SMTP system.

Two log files are generated inside !FreeSMTP.  These are called
clnt_log and mon_log, and are generated by the client and monitor+server
respectively.

For the general mail security considerations see RFC821 and RFC1123.  In
the RISC OS environment, a further consideration is that being a single-
user operating system, there is no way to prevent the Newsbase being
examined directly, or the outgoing queue to be examined, unless you have
taken specific measures to make this so.

RFC1123 Considerations
======================

Incoming addresses in both MAIL FROM and RCPT TO fields are automatically
rewritten as per RFC1123 to strip unnecessary source routeing from them.
This happens before any other processing.  (This also has the effect of
stopping hackers using source routeing as a way of using you as a mail
gateway, since after the rewrite, the destination domain will no longer
match a localdomain, and will be rejected unless you forward for that
domain)

The %-hack is supported by the address rewriter too and explicitly
removed, so hackers can't use that either.

Miscellaneous
=============

When spooling files if the file cannot be opened in spool.mail.text.user then
spool.fail.user is used instead (and the mail is bounced if that fails too).
Files in spool.fail.user are never touched again and need to be handled
manually.

I am very interested in RFC compliancy issues. E-mail
me any issues you find.


ChangeLog
=========

1.20
----

Forwarding rules code clarified - shouldn't make as many mistakes.


1.19
----

Loopback interface is checked for presence and uppishness

Low memory situations are handled better.

Miscellaneous fixes.


1.16
----

The smtp_log left open problem is definitely gone now, because the file is
gone too!  Everything is dumped in mon_log instead.

Aliases with capital letters in now work

The forwarder doesn't consider you a twat for not using MX records and
constantly override that decision. :-)


1.14
----

Local spool directory changed to be spool.mail.text.*


1.13
----

Bug in sender fixed - it was treated the successfully connection being made
to the server as an error :-/


1.12
----

Full release of the not grabbing all processing time version.  Also
contains a bug fix that cures a misinteraction caused by two concurrent
mail deliveries.  Log file closing finally sorted.  However, because of
the fix, you can't view smtp_log whilst the server is running.


1.10
----

Should be better behaved and not grab as much processor time, which should
help people using dialup links

1.09
----

Log file should be closed successfully now


1.06
----

Mail can now be sent even without a terminating linefeed.  This would have
caused mail to not be delivered.

1.05
----

DNS Resolver bug fix

1.04
----

RFC compliancy fix: doesn't try the A record if all the MX records fail.
A records only used if no MX records were found.

Extra debug information put in to try to determine the cause of some
apparent premature timing out.

Activity log notes in this document updated to cover bug reports.


1.03
----

VRFY fixed again!  It was rejecting non-local single recipient aliases
because Newsbase was saying that the user was unknown.


1.02
----

Fixed domain name processing to not add surplus > characters

EXPN procession now works properly again


1.01
----

Fixed acceptfrom and rejectfrom handling - the bitfield masks were
the wrong way around


1.00
----

TRACE removed from the sendmail transport!!

maxhops added

Vital missing headers are added to incoming mail


0.11
----

You can disable the GUI by adding 'noiconbar' to the configuration file

Some of the log messages are clearer

Bug in sendmail transport file corrected


0.10
----

Very simple Wimp interface added

Some log messages have been changed to make them sound less fatal (some
are purely informational but had alarming sounding overtones)

in_smtpd's sendmail reads the smtp-conf file to determine how to send
mail to single recipients, instead of defaulting to MX records (when
no gateway can be found, and none was given in Newsbase, multiple
mails are generated to all of the recipients via MX records)



0.09
----

Multi-line responses were confusing the SMTP sender because I'd got a
condition test round the wrong way :-(

Lock files removed - the task list is scanned instead.

Long lines were confusing things all over the place.  Although illegal,
some clients still generate this, so I allow them now too.

The socket sender had every chance of crashing if a line was to be
transmitted which was longer than 256 characters!  This is now
upped to 1024 characters (something which calling routines already
enforce)

SMTP Monitor uses an exponential backoff retry algorithm for sending mail
when it is first started - it delays 30 seconds, then 1 minute, then 2,
then 4, then 8, then 16, then every 30 minutes.  It can still be launched
manually by running !SendSMTP and will be launched whenever you send mail
locally.



Please e-mail me any problems: [e-mail]


--
Stewart Brodie
February 1997